@heineiuo Can you please merge this one in ?

Is there any reason to do this?

As upstream package (ws) has't changed type to module, I don't think it's a good timing to merge this.

I don't remember the exact details, but It has give me problems on hibrid environments, since browser import was ESM and Node.js one was CommonJS, correct aproach is to unify everything as ESM, as this PR does. After this change, everything is working flawlessly.

Any update on this? Can it be merged?

I'll keep this pr open until ws support type: module.

I'll keep this pr open until ws support type: module.

It will not happen in the foreseen: websockets/ws#1886.

I think we should NOT wait to ws doing the migration at all, and do it ourselves right now, to keep a consistent API: or both browser and Node.js support ESM, or none of them, leaving what ws currently does as an implementation detail. We can also offer both ESM and CommonJS exports for both browser and Node.js, or at least for Node.js since for browser we already migrated to ESM and deprecated to CommonJS. Would this make sense? Would you merge the PR sooner if I add support for both ESM and CommonJS, using package.json exports field?

I don't understand why, but when using isomorphic-ws with Web Dev Server, it only compiles successfully when converting node.js to ESM. Here's reproduction for it https://github.com/jost-s/wds-error-reproduction

I've raised the issue in the WDS repo too modernweb-dev/web#1700 (comment)

@heineiuo consider this solution as an alternative that you can apply today: #30 (comment)

Effectively keeping this as CJS, but exporting an equivalent ESM version separately for those that need it.

@heineiuo consider this solution as an alternative that you can apply today: #30 (comment)

Effectively keeping this as CJS, but exporting an equivalent ESM version separately for those that need it.

I like it, can you do a PR?

@heineiuo consider this solution as an alternative that you can apply today: #30 (comment)
Effectively keeping this as CJS, but exporting an equivalent ESM version separately for those that need it.

I like it, can you do a PR?

#37

@heineiuo consider this solution as an alternative that you can apply today: #30 (comment)

Effectively keeping this as CJS, but exporting an equivalent ESM version separately for those that need it.

In general, this should work better in terms of backward compatibility